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This paper presents the derivation of an executable Krivine abstract machine from a small step inter- 
preter for the simply typed lambda calculus in the dependently typed programming language Agda. 



1 Introduction 

There is a close relationship between lambda calculi with explicit substitutions and abstract machines. 
Biernacka and Danvy || 7|1 ha ve shown how to derive several well-known abstract machines including 



the Krivine machine 11 14111 51. 1211.12211 . the CEK machine [19], and the Zinc machine ||23l]. Starting with 
a functional program that evaluates by repeated head reduction, each of these abstract machines may 
be derived by a series of program transformations. Every transformation is carefully motivated in the 
accompanying text. This paper aims to nail down the correctness of these derivations further and, in the 
process, uncover even more structure. 

In this paper we show how the derivation presented by Biernacka and Danvy can be formalized in 



the dependently typed programming language Agda 12511 . What do we hope to gain by doing so? In their 



study relating evaluators and abstract machines, Ager et al. fl] state in the introduction 

Most of our implementations of the abstract machines raise compiler warnings about non- 
exhaustive matches. These are inherent to programming abstract machines in an ML-like 
language. 

This paper demonstrates that these non-exhaustive matches are not inherent to a dependently typed pro- 
gramming language such as Agda. All the functions we present here are structurally recursive and 
provide alternatives for every case branch. This shift to a dependently typed language gives us many 
properties of evaluation 'for free.' For example, from the types alone we learn that evaluation is type 
preserving and that every term can be decomposed uniquely into a redex and evaluation context. Finally, 
using Agda enables us to provide a machine-checked proof of the correctness of every transformation. 
More specifically, this paper makes the following concrete contributions: 

• We describe the implementation of a small step evaluator in Agda that normalizes by repeated 
head reduction (Section O. To convince Agda's termination checker that our definition is sound. 



we provide a normalization proof in the style of Tait |30], originally sketched by Coquand 11311 
(Sectiongll. 

Applying the refocusing transformation lisll . yields a small-step abstract machine that is not yet 
tail-recursive (Section [5ll. We prove that this transformation preserves the semantics and termina- 
tion properties of the small-step evaluator from Section |4l 
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• This small-step abstract machine can be transformed further to derive the Krivine machine (Sec- 
tion |6ll. Once again, we show that the transformation preserves the semantics and termination 
properties of the small-step abstract machine from Section |5] 

This paper is a literate Agda program. Rather than spelling out the details of every proof, we will only 
sketch the necessary lemmas and definitions. The complete source code, including proofs, is available 
onlineQ Every section in this paper defines a separate module, allowing us to reuse the same names for 
the functions and data types presented in individual sections. Finally, the code in this paper uses a short 
Agda Prelude that is included in an appendix. Readers unfamiliar with Agda may want to consult one of 
the many tutorials and introductions that are available I.10„,26,,27.1 . 



2 Types and terms 

Before we can develop the series of evaluators, we need to define the terms and types of the simply typed 
lambda calculus. 



data Ty : Set where 

: Ty 

: Ty Ty Ty 

Context : Set 
Context = List Ty 

The data type Ty represents the types of the simply typed lambda calculus with one base type 0. A 
context is defined to be a list of types. Typically the variables a and T range over types; the variables F 
and A range over contexts. 

Next we define the data types of well-typed, well-scoped variables and lambda terms: 

data Ref : Context Ty — ^ Set where 
Top : Ref (Cons a F) a 
Pop : Ref Fa Ref (Cons tF) a 

data Term : Context ^ Ty — )• Set where 
Lam : Term (Cons a F) T — Term F (a =^ t) 
App : Term F (a =^ t) — > Term F a — > Term F T 
Var : Ref Fa Term Fa 



These definitions are entirely standard. There are three constructors for the simply typed lambda calculus: 
Lam introduces a lambda, extending the context; the App constructor applies a term of type a T to 
an argument of type a; the Var constructor references a variable bound in the context. 

Note that in the typeset code presented in this paper, any unbound variables in type signatures are 
implicitly universally quantified, as is the convention in Haskell ll24ll and Epigram |28 j. When we wish to 
be more explicit about implicit arguments, we will adhere to Agda's notation of enclosing such arguments 
in curly braces. 

Next, we can define the data types representing closed terms. A closure is a term t paired with an 
environment containing closed terms for all the free variables in t. Furthermore, closed terms are closed 
under application. This yields the two mutually recursive data types defined below. 



'The source code, compatible with Agda version 2.3, is available from http: //www, cs ■ru.nl/~wouters] 



W. Swierstra 



165 



data Closed : Ty Set where 

Closure : Term Fa — )• EnvF Closed a 

Clapp : Closed {a ^ r) ^ Closed a Closed t 

data Env : Context — )• Set where 
Nil : Env Nil 

_•_ : Closed a — > EnvF Env (Cons a F) 

This is a variation of Curien's Ap -calculus, proposed by Biemacka and Danvy A similar choice of 
closed terms was independently proposed by Coquand [13]. 

The aim of evaluation is to compute a value for every closed term. Closed lambda expressions are 
the only values in our language. The final definitions in this section capture this: 

isVal : Closed a Set 

isVal (Closure (Lam body) env) = Unit 

isVal _ = Empty 

data Value (a : Ty) : Set where 

Val : (c : Closed a) — ^ isVal c — > Value a 

With these types in place, we can specify the type of the evaluation function we will define in the 
coming sections: 

evaluate : Closed a — )• Value a 



3 Reduction 

Writing t [env] to denote the closure consisting of a term t and an environment env, the four rules in below 
specify a normal-order small step reduction relation for the closed terms. In this section, we will start to 
implement these rules in Agda. 

Lookup /[ci,c2,...c„] -^c, 
App {to ti) [env] {to [env]) {ti [env]) 

Beta {{Xt) [env]) x^t[x- env] 
Left if cq Cq then cq c\ Cq c\ 

In the style of Danvy and Nielsen ifisll . we define a single reduction step in three parts. First, we 
decompose a closed term into a redex and an evaluation context. Second, we contract the redex to form 
a new closed term. Finally, we plug the resulting closed term back into the evaluation context. 

To define such a three-step reduction step, we start by defining the Redex type, corresponding to the 
left-hand sides of the first three rules above. 

data Redex : Ty — ^ Set where 

Lookup : RefFa — > EnvF — > Redex cr 

Rapp : Term F (a t) — ;> Term Fa — ^ EnvF — > Redex t 

Beta : Term (Cons a F) t — > Env F — > Closed a — )■ Redex t 



166 



From Mathematics to Abstract Machine 



Of course, every redex can be mapped back to the closed term that it represents. 

fromRedex : Redex a Closed a 

fromRedex (Lookup i env) = Closure (Var i) env 

fromRedex (Rapp fx env) = Closure (App fx) env 

fromRedex (Beta body env arg) = Clapp (Closure (Lam body) env) arg 

Next, we define the contract function that computes the result of contracting a single redex: 

_!_ : EnvT ^ RefTa Closed a 
Nil ! 

(x • _) ! Top = X 

(x • xs) ! Pop r = xs ! r 

contract : Redex a — > Closed a 
contract (Lookup i env) = env ! i 

contract (Rapp fx env) = Clapp (Closure f env) (Closure x env) 
contract (Beta body env arg) = Closure body (arg • env) 

In the Lookup case, we look up the variable from the environment using the _!_ operator. The Rapp 
case distributes the environment over the two terms. Finally, Beta reduction extends the environment 
with the argument arg, and uses the extended environment to create a new closure from the body of a 
lambda. Once again, the definition of the contract function closely follows the first three reduction rules 
that we formulated above. 

While this describes how to contract a single redex, we still need to define the decomposition of 
a term into a redex and a reduction context. We begin by defining an evaluation context as the list of 
arguments encountered along the spine of a term: 

data EvalContext : Ty ^ Ty — )• Set where 
MT : EvalContext a a 

ARG : Closed a — ^ EvalContext T p ^ EvalContext (a ^ t) p 

Ignoring the Ty indices for the moment, an evaluation context is simply a list of closed terms. Given 
any evaluation context ctx and term t, we would like to plug t in the context by iteratively applying t to 
all the arguments in ctx. For this to type check, the term t should abstract over all the variables in the 
evaluation context. We enforce this by indexing the EvalContext type by the 'source' and 'destination' 
types in the style of Atkey [3]. The plug operation itself then applies any arguments from the evaluation 
context to its argument term: 

plug : EvalContext a T ^ Closed a — > Closed t 
plug MTf = f 

plug (ARG x ctx) f = plug ctx (Clapp fx) 
Finally, we define the decomposition of a closed term into a redex and evaluation context as a 



view Il24l 13 111 on closed terms. Defining such a view consists of two parts: a data type Decomposition 
indexed by a closed term, and a function decompose that maps every closed term to its Decomposition. 

We will start by defining a data type Decomposition. There are two constructors, corresponding to 
the two possible outcomes of decomposing a closed term c: either c is a value, in which case we have 
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the closure of a Lam-term and an environment; alternatively, c can be decomposed into a redex r and 
an evaluation context ctx, such that plugging the term corresponding to r in the evaluation context ctx is 
equal to the original term c: 

data Decomposition : Closed a — )• Set where 

Val : (body : Term (Cons a F) t) — (env : EnvF) — >■ 

Decomposition (Closure (Lam body) env) 
Decompose : (r : Redex a) — )• (ctx : EvalContext a t) — )■ 

Decomposition (plug ctx (fromRedex r)) 

Next we show how every closed term c can be decomposed into a Decomposition c. We do so by 
defining a pair of functions, load and unload. The load function traverses the spine of c, accumulating 
any arguments we encounter in an evaluation context until we find a redex or a closure containing a 
Lam. The unload function inspects the evaluation context that load has accumulated in order to decide 
if a lambda is indeed a value, or whether it still has further arguments, and hence corresponds to a Beta 
redex: 

load : (ctx : EvalContext cr t) (c : Closed a) Decomposition (plug ctx c) 

load ctx (Closure (Lam body) env) = unload ctx body env 

load ctx (Closure (App fx) env) = Decompose (Rapp fx env) ctx 

load ctx (Closure (Var i) env) = Decompose (Lookup i env) ctx 

load ctx (Clapp f x) = load (ARC x ctx) f 

unload : (ctx : EvalContext (a =^ t) p) (body : Term (Cons a F) t) (env : EnvF) 

— )• Decomposition (plug ctx (Closure (Lam body) env)) 
unload MT body env = Val body env 

unload (ARC arg ctx) body env = Decompose (Beta body env arg) ctx 

The decompose function itself simply kicks off load with an initially empty evaluation context. 

decompose : (c : Closed a) Decomposition c 
decompose c = load MTc 

To perform a single reduction step, we decompose a closed term. If this yields a value, there is no 
further reduction to be done. If decomposition yields a redex and evaluation context, we contract the 
redex and plug the result back into the evaluation context: 

headReduce : Closed a — > Closed o 
headReduce c with decompose c 

headReduce [Closure (Lam body) envj | Val body env = Closure (Lam body) env 
headReduce [plug ctx (fromRedex redex) J | Decompose redex ctx = plug ctx (contract redex) 

Note that pattern matching on the Decomposition produces more information about the term that has 
been decomposed. This is apparent in the forced patterns [25], [Closure (Lam body) envJ in the Val 
branch and [plug ctx (fromRedex redex)J in the Decompose branch, that appear on the left-hand side of 
the function definition. 

This completes our definition of a single head reduction step. 
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4 Iterated head reduction 

In the previous section we established how to perform a single reduction step. Now it should be straight- 
forward to define an evaluation function by iteratively reducing by a single step until we reach a value: 

evaluate : Closed a — )• Value a 
evaluate c = iterate (decompose c) 
where 

iterate : Decomposition c — > Value cr 
iterate (Val val p) = Val val p 

iterate (Decompose r ctx) = iterate (decompose (plug ctx (contract r))) 

There is one problem with this definition: it is not structurally recursive. It is rejected by Agda. 
Yet we know that the simply typed lambda calculus is strongly normalizing — so iteratively performing a 
single head reduction will always produce a value eventually. How can we convince Agda of this fact? 

The Bove-Capretta method is one technique to transform a definition that is not structurally recursive 
into an equivalent definition that is structurally recursive over a new argument [9]. Essentially, it does 
structural recursion over the call graph of a function. In our case, we would Uke to have an inhabitant of 
the following data type: 

data Trace : {c : Closed a} — )■ Decomposition c — )• Set where 

Done : (body : Term (Cons a F) t) (env : Env F) — > Trace (Val body env) 
Step : Trace (decompose (plug ctx (contract r))) Trace (Decompose r ctx) 

We could then define the iterate function by structural induction over the trace: 

iterate : {c : Closed a} (d : Decomposition c) ^ Traced Value a 
iterate (Val body env) (Done [bodyj [envj) = Val (Closure (Lam body) env) unit 
iterate (Decompose r ctx) (Step step) = iterate (decompose (plug ctx (contract r))) step 

Although this definition does pass Agda's termination checker, the question remains how to provide the 
required Trace argument to our iterate function. That is we would like to define a function of type: 

(t : Closed a) — )• Trace t 

A straightforward attempt to define such a function fails immediately. Instead, we need to define the 
following logical relation that strengthens our induction hypothesis: 

Reducible : {a : Ty} (t : Closed a) Set 

Reducible {0} t = Trace (decompose t) 

Reducible {a =^ rjt = Pair (Trace (decompose t)) 

((x : Closed a) Reducible x Reducible (Clapp tx)) 

ReducibleEnv : EnvF — )• Set 
ReducibleEnv Nil = Unit 

ReducibleEnv (x • env) = Pair (Reducible x) (ReducibleEnv env) 



To prove that all closed terms are reducible, we follow the proof sketched by Coquand il3l] and prove 
the following two lemmas. 
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lemmal : (c : Closed c) — > Reducible (headReduce c) — >■ Reducible c 

Iemma2 : (t : Term Per) (env : EnvF) ReducibleEnv env — >■ Reducible (Closure t env) 

The proof of Iemma2 performs induction on the term t. In each of the branches, we appeal to lemmal in 
order to prove that Closure t env is also reducible. The proof of lemmal is done by induction on a and 
c. The only difficult case is that for closed applications, Clapp fx. In that branch, we need to show that 
Clapp (headReduce (Clapp fx)) y is equal to headReduce (Clapp (Clapp fx) y). 

To prove the desired equality we observe that if decomposing Clapp fx yields a redex r and evaluation 
context ctx, then the decomposition of Clapp (Clapp fx) y must yield the same redex with the evaluation 
context obtained by adding y to the end of ctx. To complete the proof we define an auxiliary 'backwards 
view' on evaluation contexts that states that every evaluation context is either empty or arises by adding 
a closed term to the end of an evaluation context. Using this view, the required equality is easy to prove. 

Using lemmal and Iemma2, we can prove our main theorem: every closed term is reducible. To do 
so, we define the following two mutually recursive theorems: 

mutual 

theorem : (c : Closed a) — > Reducible c 

theorem (Closure t env) = Iemma2 1 env (envTheorem env) 

theorem (Clapp fx) = snd (theorem f) x (theorem x) 

envTheorem : (env : EnvF) ReducibleEnv env 
envTheorem Nil = unit 

envTheorem (t • ts) = (theorem t, envTheorem ts) 

To prove that every closure is reducible, we appeal to Iemma2 and prove that every closed term in the 
environment is also reducible. The proof that every closed application is reducible recurses over both 
arguments f and x. The recursive call to f yields a pair of a trace and a function of type: 

((x : Closed cy) Reducible x — >■ Reducible (Clapp fx)) 

Applying this function to x and theorem x, yields the desired proof. 

One important corollary of our theorem is that for every closed term c, we can compute an evaluation 
trace of c: 

termination : {o : Ty} — > (c : Closed cy) — )■ Trace (decompose c) 
termination {0} c = theorem c 
termination {cj =^ t}c = fst (theorem c) 

Now we can finally complete the definition of our small step evaluation function: 

evaluate : Closed o — )• Value a 

evaluate t = iterate (decompose t) (termination t) 

The evaluate function iteratively performs a single step of head reduction, performing structural induc- 
tion over the trace that we compute using the reducibility proof sketched above. 

5 Refocusing 

The small step evaluator presented in the previous section repeatedly decomposes a closed term into an 
evaluation context and a redex, contracts the redex, and plugs the contractum back into the evaluation 
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context. Before transforming this evaluator into the Krivine machine, we will show how to apply the re- 
focusing transformation to produce a small-step abstract machine (v^. This small-step abstract machine 
forms a convenient halfway point between the small step evaluator and the Krivine machine. 

The key idea of refocusing is to compose the plugging and decomposition steps into a single refocus 
operation. Instead of repeatedly plugging and decomposing, the refocus function navigates directly to 
the next redex, if it exists: 

refocus : (ctx : Eva I Context a t) (c : Closed a) — )■ Decomposition (plugctxc) 
refocus MT (Closure (Lam body) env) = Val body env 

refocus (ARC x ctx) (Closure (Lam body) env) = Decompose (Beta body env x) ctx 
refocus ctx (Closure (Var i) env) = Decompose (Lookup i env) ctx 
refocus ctx (Closure (App fx) env) = Decompose (Rapp fx env) ctx 
refocus ctx (Clapp fx) = refocus (ARC x ctx) f 

We can formalize this intuition about the behaviour of refocusing by proving the following lemma: 

refocusCorrect : (ctx : EvalContext a t) (c : Closed a) — > 
refocus ctx c = decompose (plug ctx c) 

The proof by induction on ctx and c relies on an easy lemma: 

decomposePlug : (ctx : EvalContext a t) (c : Closed a) — )• 
decompose (plug ctx c) = load ctx c 

The proof of the decomposePlug lemma proceeds by simple induction on the evaluation context. 

To rewrite our evaluator to use the refocus operation, we will need to adapt the Trace data type from 
the previous section. Iterated recursive calls will no longer call decompose and plug, but instead navigate 
to the next redex using the refocus function. The new Trace data type reflects just that: 

data Trace : Decomposition c — > Set where 

Done : (body : Term (Cons a F) t) (env : EnvF) — > Trace (Val body env) 
Step : Trace (refocus ctx (contract r)) — > Trace (Decompose r ctx) 

To prove that this new Trace data type is inhabited, we call the termination lemma from the previous 
section. Using the refocusCorrect lemma, we perform induction on the Trace data type from the previous 
section to construct a witness of termination. All this is done by the following termination function: 

termination : (c : Closed a) — Trace (refocus MT c) 

The definition of our evaluator is now straightforward. The iterate function repeatedly refocuses and 
contracts until a value has been reached: 

iterate : (d : Decomposition c) — Traced Value a 

iterate (Val body env) (Done [bodyj [envj) = Val (Closure (Lam body) env) unit 
iterate (Decompose r ctx) (Step step) = iterate (refocus ctx (contract r)) step 

evaluate : Closed a — )• Value a 

evaluate c = iterate (refocus MT c) (termination c) 
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The evaluate function kicks off the iterate function with an empty evaluation context and a proof of 
termination. 

Finally, we can also show that our new evaluator behaves the same as the evaluation function pre- 
sented in the previous section. To do so, we prove the following lemma by induction on the decomposi- 
tion of t: 

correctness : {t : Closed cj} ^ 

(trace : Trace (refocus MT t)) (trace' : Section4. Trace (decompose t)) — > 
iterate (refocus MT t) trace = Section4. iterate (decompose t) trace' 

An important corollary of this correctness property is that our new evaluation function behaves identi- 
cally to the evaluate function from the previous section: 

corollary : (t : Closed a) evaluate t = Section4. evaluate t 
corollary t = correctness (termination t) (Section4. termination t) 

This completes the definition and verification of the evaluator that arises by applying the refocusing 
transformation on the small step evaluator from Section IH 



6 The Krivine machine 

In this section we will derive the Krivine machine from the evaluation function we saw previously. To 
complete our derivation, we perform a few further program transformations on the previous evaluation 
function. 

We start by inlining the iterate function, making our refocus function recursive. Furthermore, the 
evaluate function in the previous section mapped App terms into closed Clapp terms, and subsequently 
evaluated the first argument of the resulting Clapp constructor, adding the second argument to the evalu- 
ation context. In this section, we will combine these two steps into a single transition — a transformation 



sometimes referred to as compressing corridor transitions II16I1 . As a result, we will no longer add closed 
applications to the environment or evaluation context. We introduce the following predicates enforcing 
the absence of Clapp constructors on closed terms, environments, and evaluation contexts respectively: 

mutual 

isValidClosure : Closed a — )• Set 
isValidClosure (Closure t env) = isValidEnv env 
isValidClosure (Clapp fx) = Empty 

isValidEnv : Env A Set 
isValidEnv Nil = Unit 

isValidEnv (c • env) = Pair (isValidClosure c) (isValidEnv env) 

isValidContext : EvalContext a T ^ Set 
isValidContext MT = Unit 

isValidContext (ARC (Closure t env) ctx) = Pair (isValidEnv env) (isValidContext ctx) 
isValidContext (ARC (Clapp fx) env) = Empty 
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Given that the only valid closed terms are closures, we can define functions that project the underlying 
environment and term from any valid closed term: 

getContext : Exists (Closed o) isValidClosure Context 

getContext (Witness (Closure {F} tenv) _) = F 
getContext (Witness (Clapp fx) ()) 

getEnv : (c : Exists (Closed a) isValidClosure) Env (getContext c) 
getEnv (Witness (Closure tenv) p) = env 
getEnv (Witness (Clapp fx) ()) 

get Term : (c : Exists (Closed o) isValidClosure) — > Term (getContext c) o 
get Term (Witness (Closure t env) p) = t 
get Term (Witness (Clapp fx) ()) 

Finally, we can define a new lookup operation that guarantees that looking up a variable in a valid 
enviroimient will always return a closure: 

lookup : RefF<T — > (env : EnvF) — >■ IsValidEnv env 

Exists (Closed a) isValidClosure 
lookup Top (Closure t env • _) (pi, p2) = Witness (Closure t env) pi 

lookup Top (Clapp • _) ((),-) 

lookup (Pop i) (_ • env) (_, p) = lookup i env p 

If the argument reference is Top, we pattern match on the environment, which must contain a closure. 
We use the proof that the environment contains exclusively closures to discharge the Clapp branch. If 
the argument reference is Pop i, we recurse over i and the tail of the environment. 

Once again, we define a Trace data type, describing the call-graph of the Krivine machine. The 
Trace data type is indexed by the three arguments to the Krivine machine: a term, an environment, and 
an evaluation context. The data type has a constructor for every transition; recursive calls to the abstract 
machine correspond to recursive arguments to a constructor: 

data Trace : Term Fa EnvF Eva I Context a T Set where 
Lookup : (i : RefFcx) (p : isValidEnv env) — > 
let c = lookup i env p in 

Trace (get Term c) (getEnv c) ctx — > Trace (Var i) env ctx 
App : (f : Term F (a z)) (x : Term F a) — > 

Trace f env (ARC (Closure x env) ctx) 

Trace (App fx) env ctx 
Beta : (ctx : Eva I Context op) — 

(arg : Term H t) ^ (argEnv : Env H) — > 

(body : Term (Cons t F) a) — >■ 

Trace body (Closure arg argEnv ■ env) ctx — )■ 

Trace (Lam body) env (ARG (Closure arg argEnv) ctx) 
Done : (body : Term (Cons T F) cj) Trace (Lam body) env MT 

Using this Trace, we can now define the final version of the refocus function, corresponding to the 
Krivine abstract machine, by structural recursion on this Trace. The resulting machine corresponds to 
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the Krivine machine as is usually presented in the literature 114, 15, 21]. Biemacka and Danvy ^ also 



consider the derivation of Krivine's original machine 122 1 that contracts nested j8 -reductions in one step. 

refocus : (ctx : EvalContext a t) (t : Term Fa) (env : EnvF) — )• 

Trace t env ctx — > Valuer 
refocus ctx [Var ij env (Lookup i q step) = 

let c = lookup i env q in 

refocus ctx (get Term c) (getEnv c) step 
refocus ctx [App f xj env (App f x step) 

= refocus (ARG (Closure x env) ctx) f env step 
refocus [ARG (Closure arg env') ctxj [Lam bodyj env (Beta ctx arg env' body step) 

= refocus ctx body ((Closure arg env') • env) step 
refocus [MTJ [Lam bodyJ env (Done body) = Val (Closure (Lam body) env) unit 

In the case for variables, we look up the closure that the variable refers to in the environment, and con- 
tinue evaluation with that closure's term and environment. In the case for App fx, we add the argument 
and current environment to the application context, and continue evaluating the term f. We distinguish 
two further cases for lambda terms: if the evaluation context is not empty, we can perform a beta reduc- 
tion step; otherwise evaluation is finished. 

We still need to prove that the Trace data type is inhabited. During execution, the Krivine machine 
only adds closures to the environment and evaluation context. During the termination proof, we will 
need to keep track of the following invariant on evaluation contexts and environments: 

invariant : EvalContext a T — EnvF — Set 

invariant ctx env = Pair (isValidEnv env) (isValidContext ctx) 

The proof of termination once again calls the termination proof from the previous section. An auxiliary 
lemma shows that any witness of termination for the small-step abstract machine in Section |5] will also 
suffice as a proof of termination of the Krivine machine. 

termination : (t : Term Nil a) — ^ Trace t Nil MT 

termination t = lemma MTtNil (unit, unit) (Section5. termination (Closure t Nil)) 
where 

lemma : (ctx : EvalContext a t) (t : Term Fa) (env : EnvF) 

invariant ctx env Sections. Trace (Sections. refocus ctx (Closure t env)) — )• 
Trace t env ctx 



The lemma is proven by straightforward induction on the evaluation context, the term, and the Trace data 
type from the previous section. Once we pattern match on the term and the evaluation context, we know 
which transition we wish to make, and hence which constructor of the Trace data type is required. Any 
recursive occurrences of the Trace data type can be produced by recursive calls to the lemma. The only 
other result necessary states that the lookup function and the _!_ operation we saw previously return 
the same closed term from an environment. 

Finally, we can define the evaluation function that calls refocus with a suitable choice for its initial 
arguments: 

evaluate : Term Nil a Value a 

evaluate t = refocus MT t Nil (termination t) 
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To conclude, we show that this final version of the refocus function behaves equivalently to the 
refocus function from the previous section. To prove this, we formulate the correctness property below. 

correctness : (ctx : Eva I Context a t) (t : Term F a) (env : EnvF) — > 
(ti : Trace t env ctx) — )• 

(t2 : Sections. Trace (Sections. refocus ctx (Closure t env))) — )• 

refocus ctx t env ti = Sections. iterate (Sections. refocus ctx (Closure t env)) t2 

Once again, the proof proceeds by straightforward induction on the traces. 

As a result of this correctness property, we can prove that our evaluation function behaves the same 
as the function presented in the previous section: 

corollary : (t : Term Nil a) evaluate t = Sections. evaluate (Closure t Nil) 
corollary t = let trace = termination t in 

let trace' = Sections. termination (Closure t Nil) in 

correctness MT t Nil trace trace' 

By chaining together our correctness results, we can show that our Krivine machine produces the 
same value as our original evaluator based on repeated head reduction, thereby completing the formal 
derivation of the Krivine machine from a small step evaluator. 



7 Discussion 

There has been previous work on formalizing the derivations of abstract machines in Coq 0, [i^. In 
contrast to the development here, these formalizations are not executable but instead define the reduction 
behaviour as inductive relations between terms and values. The executability of our abstract machines 
comes at a price: we need to prove that the evaluators terminate, which requires a clever logical relation. 
On the other hand, it is easier to reason about executable functions. In type theory, definitional equalities 
are always trivially true — a fact you can only exploit if your functions compute. 

This paper uses the Bove-Capretta method to prove termination of every evaluator. Chapman and 
Altenkirch use a similar logical relation to produce inhabitants of Bove-Capretta predicates when writing 
a big-step normalization algorithm There are, of course, alternative methods to show that a non- 
structurally recursive function does terminate. For example, it may be interesting to investigate how 
to adapt the normalization proof to use an order on lambda terms proposed by Gandy [20] to define a 
suitable accessibility relation. 

Finally, you may wonder if the usage of logical relations to prove termination is 'cheating.' After 
all, the computational content of normalization proofs using logical relations is itself a normalization 
algorithm [4, 5, ^ — so is our small-step evaluator not just reading off the value from the trace that our 
proof computes? Not at all! In fact, the behaviour of the iterate function from Section|4]is independent 
of the trace we provide — once the iterate function matches on the argument decomposition, the trace 
passed as an argument to the iterate function is uniquely determined. The following statement is easy to 
prove: 

collapsible : (d : Decomposition c) (ti t2 : Trace d) — )• ti = t2 
In other words, the traces themselves c arry no computational content. Such collapsible data types may 



be erased by a suitable clever compiler ||11L I12|1. 

This paper focuses on the derivation of the Krivine abstract machine. There is no reason to believe 
that the other derivations of abstract machines [tIi may not be formalized in a similar fashion. 
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A An Agda Prelude 

module Prelude where 

id : forall {a : Set} — > a — >■ a 

id X = X 

data Empty : Set where 

magic : forall {a : Set} Empty — > a 
magic 

record Unit : Set where 

unit : Unit 

unit = record { } 

data Pair (a b : Set) : Set where 
_, _ : a ^ b — > Pair a b 

fst : forall {a b} — > Pair a b -> a 
fst (x, _) = X 

snd : forall {a b} — > Pair a b — )■ b 

snd (_,y) = y 

data List (a : Set) : Set where 
Nil : List a 

Cons : a List a — )■ List a 

data _ = _ {a : Set} (x : a) : a — > Set where 
Refl : X = X 

infix 6_ = _ 

sym : {a : Set} {xy:a}— >-x = y— )-y = x 
sym Refl = Refl 

cong : {a b : Set} {xy:a} — )• (f:a — > b) ^x = y^fx = fy 
congfRefl = Refl 

data Exists (a : Set) (b : a ^ Set) : Set where 
Witness : (x : a) — >■ b x ^ Exists a b 

fsts : forall {a b} — ^ Exists a b — )■ a 
fsts (Witness x _) = x 

snds : forall {a b} — > (x : Exists a b) — > (b (fstsx)) 
snds (Witness _ y) = y 



